6장. AI 답변을 검증하고 개선하는 방법

1. AI 답변은 완성품이 아니라 초안이다

AI는 매우 빠르게 답변을 만든다.

코드도 작성하고, 문서도 정리하고, 장애 원인도 추정하고, 보고서 초안도 만들어준다.

그래서 AI 답변을 보면 바로 사용해도 될 것처럼 느껴질 때가 많다.

하지만 실무에서는 AI 답변을 완성품으로 보면 안 된다.
AI 답변은 기본적으로 초안으로 보는 것이 안전하다.

예를 들어 AI에게 로그인 API 코드를 만들어달라고 하면 꽤 그럴듯한 코드가 나온다.

app.post('/login', async (req, res) => {
    const {email, password} = req.body;

    const user = await userRepository.findByEmail(email);

    if (!user) {
        return res.status(401).json({message: 'Invalid email or password'});
    }

    const isValid = await bcrypt.compare(password, user.password);

    if (!isValid) {
        return res.status(401).json({message: 'Invalid email or password'});
    }

    const token = jwt.sign({userId: user.id}, process.env.JWT_SECRET);

    return res.json({token});
});

겉으로 보기에는 괜찮아 보인다.

하지만 실제 운영 코드라면 추가로 확인할 것이 많다.

- req.body가 없을 때 예외 처리가 되는가?
- email과 password 입력값 검증이 있는가?
- 로그인 실패 횟수 제한이 있는가?
- JWT 만료 시간이 설정되어 있는가?
- JWT_SECRET이 없을 때 어떻게 되는가?
- 비밀번호나 토큰이 로그에 노출되지 않는가?
- 관리자와 일반 사용자 권한 처리는 분리되어 있는가?

AI가 만든 코드는 시작점으로는 좋다.

하지만 실제 서비스에 넣기 전에는 반드시 개발자가 검토해야 한다.

AI가 문서를 작성해준 경우도 마찬가지다.

장애 보고서 초안을 만들 수는 있지만, 원인이 확정되지 않았는데 단정적으로 작성했을 수 있다.
비용 비교표를 만들 수는 있지만, 실제 가격이 최신이 아닐 수 있다.
보안 체크리스트를 만들 수는 있지만, 회사 내부 정책과 맞지 않을 수 있다.

그래서 AI 답변을 볼 때는 다음 관점이 필요하다.

AI가 만든 결과물
→ 초안으로 활용
→ 사실 확인
→ 누락 검토
→ 위험 요소 확인
→ 우리 상황에 맞게 수정
→ 최종 사용

AI를 잘 쓰는 개발자는 AI 답변을 그대로 복사해서 쓰는 사람이 아니다.

AI가 만든 초안을 빠르게 검토하고, 실무에 맞게 다듬을 수 있는 사람이다.

2. AI 답변에서 가장 먼저 봐야 할 것

AI 답변을 받으면 바로 “괜찮아 보이네”라고 판단하면 안 된다.

먼저 답변 안에 어떤 종류의 내용이 섞여 있는지 봐야 한다.

AI 답변에는 보통 다음 네 가지가 섞여 있다.

- 사실
- 추정
- 의견
- 제안

예를 들어 장애 로그를 AI에게 보여주고 원인을 물어봤다고 해보자.

AI가 이렇게 답했다고 가정해보자.

Redis 응답 지연이 발생했고, 이로 인해 API 응답 시간이 증가했습니다.
원인은 Redis 메모리 부족으로 보입니다.
따라서 Redis 인스턴스 스펙을 올리는 것이 좋습니다.

이 답변을 그대로 믿으면 위험하다.

내용을 나눠보면 다음과 같다.

AI 답변의 문제는 이 네 가지가 자연스럽게 섞여 나온다는 점이다.

사람이 읽으면 모두 사실처럼 느껴질 수 있다.

하지만 실무에서는 반드시 구분해야 한다.

사실:
로그, 코드, 문서, 지표로 확인 가능한 내용

추정:
현재 정보로 가능성이 있어 보이지만 확정되지 않은 내용

의견:
AI가 판단한 해석이나 우선순위

제안:
문제를 해결하기 위한 방법

특히 장애, 보안, 비용, 법률, 개인정보, 인프라 작업에서는 이 구분이 매우 중요하다.

확인되지 않은 추정을 사실처럼 보고하면 잘못된 의사결정으로 이어질 수 있다.

3. 사실과 추정을 구분해야 한다

AI가 작성한 답변을 검토할 때 가장 중요한 작업 중 하나는 사실과 추정을 나누는 것이다.

예를 들어 AI가 다음과 같이 답했다고 하자.

장애 원인은 DB 커넥션 풀 부족입니다.
트래픽 증가로 인해 커넥션이 모두 소진되었고,
그 결과 API 응답 지연이 발생했습니다.

이 답변은 그럴듯하다.

하지만 정말 DB 커넥션 풀이 원인인지 확인하려면 근거가 필요하다.

확인해야 할 것:
- 장애 시간대 DB 커넥션 사용량
- 커넥션 풀 최대치 도달 여부
- API 응답 시간 증가 시점
- DB Slow Query 발생 여부
- 배포나 설정 변경 여부
- 트래픽 증가 여부

이런 근거 없이 “원인은 DB 커넥션 풀 부족”이라고 단정하면 위험하다.

더 안전한 표현은 다음과 같다.

확인된 사실:
- 장애 시간대 API 응답 지연이 발생했다.
- 일부 요청에서 DB 응답 시간이 증가했다.

추정되는 원인:
- DB 커넥션 풀 부족 가능성이 있다.
- Slow Query 증가 가능성도 함께 확인이 필요하다.

추가 확인 필요:
- 장애 시간대 커넥션 풀 사용량
- DB Slow Query 로그
- 배포 이력
- 트래픽 변화

이렇게 사실과 추정을 나누면 보고서의 신뢰도가 높아진다.

개발 문서에서도 마찬가지다.

AI가 “이 코드는 SQL Injection에 취약합니다”라고 말하면,
정말 취약한지 확인해야 한다.

확인할 것:
- 사용자 입력값이 SQL 문자열에 직접 연결되는가?
- Prepared Statement를 사용하는가?
- ORM이 파라미터 바인딩을 처리하는가?
- 입력값 검증이 있는가?

AI가 말한 내용을 그대로 받아들이기보다,
그 판단이 어떤 근거에서 나온 것인지 확인해야 한다.

SQL Injection은 사용자 입력값을 악의적으로 조작해 SQL 쿼리 구조를 바꾸는 공격 방식이다.
보통 Prepared Statement나 파라미터 바인딩을 사용해 방어한다.

4. 근거가 없는 답변은 다시 물어봐야 한다

AI 답변이 그럴듯해도 근거가 없으면 실무에 사용하기 어렵다.

예를 들어 AI가 이렇게 답했다고 해보자.

이 구조에서는 Lambda보다 ECS가 더 적합합니다.

이 문장만 보면 결론은 있지만 근거가 부족하다.

왜 ECS가 더 적합한지, 어떤 조건에서 그런지, 반대 상황은 없는지 알 수 없다.

이럴 때는 AI에게 다시 물어봐야 한다.

방금 결론의 근거를 항목별로 설명해줘.

비교 기준:
- 비용
- 운영 부담
- 확장성
- 배포 방식
- 장애 대응

그러면 답변이 더 검토 가능한 형태로 바뀐다.

- 비용: 요청량이 적으면 Lambda가 유리할 수 있으나, 장시간 실행 작업이 많으면 ECS가 예측 가능할 수 있음
- 운영 부담: Lambda는 서버 관리 부담이 적고, ECS는 컨테이너 운영이 필요함
- 확장성: 둘 다 확장 가능하지만 트래픽 패턴에 따라 다름

근거가 나오면 개발자는 그 근거가 우리 상황과 맞는지 판단할 수 있다.

AI 답변을 검토할 때는 다음 질문을 해보면 좋다.

- 이 주장의 근거는 무엇인가?
- 제공된 정보만으로 이 결론을 낼 수 있는가?
- 다른 가능성은 없는가?
- 어떤 조건에서는 반대 결론이 나올 수 있는가?
- 실제 확인해야 할 자료는 무엇인가?

근거가 없는 AI 답변은 결론처럼 보여도 아직 사용할 수 없다.

근거를 확인할 수 있어야 실무 판단에 사용할 수 있다.

5. AI가 누락한 내용을 찾아야 한다

AI 답변이 틀리지 않았더라도, 중요한 내용이 빠져 있을 수 있다.

이것도 실무에서는 큰 문제다.

예를 들어 AI에게 “AI 고객 문의 요약 기능을 만들 때 고려할 점”을 물어봤다고 해보자.

AI가 다음과 같이 답할 수 있다.

- 요약 품질
- 응답 속도
- 비용
- 관리자 화면 UX

틀린 말은 아니다.

하지만 중요한 내용이 빠져 있을 수 있다.

- 개인정보 마스킹
- 상담 로그 보관 정책
- AI 답변 오류 시 책임 범위
- 요약 결과 수정 가능 여부
- 원문과 요약본의 연결
- 관리자 권한별 접근 제어

AI 답변이 맞아 보인다고 해서 충분하다는 뜻은 아니다.

특히 실무에서는 누락된 항목이 더 위험할 수 있다.

코드에서도 마찬가지다.

AI가 로그인 API를 만들어줬지만 다음 내용이 빠질 수 있다.

- rate limit
- 로그인 실패 횟수 제한
- 계정 잠금 정책
- 비밀번호 만료 정책
- MFA 적용 여부
- 감사 로그

문서에서도 누락이 생길 수 있다.

AI가 장애 보고서를 작성했지만 다음 항목이 빠질 수 있다.

- 장애 영향 범위
- 발생 시간과 복구 시간
- 고객 영향 여부
- 임시 조치와 근본 조치 구분
- 재발 방지 대책
- 후속 담당자

그래서 AI 답변을 검토할 때는 “틀린 내용이 있는가?”뿐 아니라,
“빠진 내용은 없는가?”를 함께 봐야 한다.

누락을 찾기 위해서는 체크리스트가 유용하다.

AI 답변 누락 검토:
- 보안 관점에서 빠진 것은 없는가?
- 운영 관점에서 빠진 것은 없는가?
- 비용 관점에서 빠진 것은 없는가?
- 사용자 경험 관점에서 빠진 것은 없는가?
- 장애 대응 관점에서 빠진 것은 없는가?
- 법무/개인정보 관점에서 빠진 것은 없는가?

AI 답변은 평균적인 답변을 잘 만든다.

하지만 우리 서비스에 꼭 필요한 특수 조건은 개발자가 확인해야 한다.

6. 코드 답변은 반드시 실행해봐야 한다

AI가 작성한 코드가 자연스럽고 깔끔해 보여도 실제로 동작하지 않을 수 있다.

가장 기본적인 검증은 실행이다.

예를 들어 AI가 다음 코드를 만들어줬다고 해보자.

const result = await userRepository.findByEmail(email);

if (result.length === 0) {
    return null;
}

return result[0];

이 코드는 findByEmail이 배열을 반환한다는 전제가 있다.

하지만 실제 프로젝트의 findByEmail 함수가 객체 하나 또는 null을 반환한다면 이 코드는 오류가 난다.

const user = await userRepository.findByEmail(email);

if (!user) {
    return null;
}

return user;

AI는 프로젝트 내부 함수의 실제 반환 형식을 모를 수 있다.

그래서 AI가 만든 코드는 반드시 현재 프로젝트 기준으로 확인해야 한다.

코드 검증 시 확인할 항목은 다음과 같다.

- 실제로 실행되는가?
- 문법 오류는 없는가?
- 사용하는 라이브러리 버전과 맞는가?
- 기존 함수의 입력/출력 형식과 맞는가?
- 예외 상황을 처리하는가?
- 테스트를 통과하는가?
- 보안상 위험한 처리는 없는가?
- 기존 비즈니스 로직을 깨지 않는가?

특히 AI는 존재하지 않는 함수나 옵션을 만들어낼 수 있다.

예를 들어 이런 코드가 나올 수 있다.

app.use(express.secureMode(true));

그럴듯해 보이지만 Express에 이런 기본 옵션은 없다.

또는 특정 라이브러리에서 오래전에 사용하던 문법을 최신 방식처럼 제안할 수도 있다.

따라서 코드 답변은 반드시 다음 순서로 확인하는 것이 좋다.

1. 문법 확인
2. 실행 확인
3. 테스트 작성 또는 기존 테스트 실행
4. 라이브러리 공식 문서 확인
5. 보안 검토
6. 실제 프로젝트 스타일에 맞게 수정

AI 코드는 복사해서 붙여넣는 것이 아니라,
검토하고 가져다 쓰는 코드 조각으로 봐야 한다.

7. SQL 답변은 실행 계획까지 확인해야 한다

AI는 SQL도 잘 작성한다.

하지만 AI가 작성한 SQL이 실제 운영 환경에서 안전하고 빠르다는 보장은 없다.

예를 들어 AI가 다음 쿼리를 제안했다고 해보자.

SELECT *
FROM users
WHERE nickname LIKE '%test%'
ORDER BY created_at DESC LIMIT 20;

이 쿼리는 문법적으로는 맞을 수 있다.

하지만 데이터가 수백만 건이라면 성능 문제가 생길 수 있다.

특히 LIKE '%test%'는 일반 인덱스를 타기 어렵다.
또 SELECT *는 필요 없는 컬럼까지 읽을 수 있다.

SQL 답변은 다음을 확인해야 한다.

- 실제 DB에서 실행되는가?
- 대상 테이블의 데이터 건수는 어느 정도인가?
- 인덱스를 사용할 수 있는가?
- 실행 계획이 적절한가?
- 정렬과 페이징에서 병목이 생기지 않는가?
- 잠금 문제가 생기지 않는가?
- 운영 DB에서 실행해도 안전한가?

SQL에서는 실행 계획이 중요하다.

실행 계획은 DB가 쿼리를 어떤 방식으로 처리할지 보여주는 정보다.

예를 들어 MySQL에서는 EXPLAIN을 사용해 확인할 수 있다.

EXPLAIN
SELECT id, nickname, created_at
FROM users
WHERE status = 'ACTIVE'
ORDER BY created_at DESC LIMIT 20;

AI가 인덱스를 추천해도 실제 데이터 분포에 따라 효과가 다를 수 있다.

예를 들어 status 컬럼에 값이 거의 ACTIVE라면 단독 인덱스 효과가 낮을 수 있다.

users 테이블 상태값 분포:
- ACTIVE: 95%
- SUSPENDED: 3%
- WITHDRAWN: 2%

이런 경우 단순히 status 인덱스를 추가하는 것이 큰 도움이 안 될 수 있다.

SQL은 데이터 규모와 분포에 크게 영향을 받는다.

AI가 만든 SQL은 문법보다 운영 데이터 기준으로 검증해야 한다.

실행 계획은 DB가 쿼리를 처리하는 방식을 보여주는 정보다.
어떤 인덱스를 사용하는지, 몇 건을 읽는지, 정렬이 필요한지 등을 확인할 수 있다.

8. 문서 답변은 목적과 독자에 맞는지 확인해야 한다

AI는 문서를 빠르게 작성한다.

보고서, 회의록, 메일, 공지문, 기술 문서 초안을 만들 때 매우 유용하다.

하지만 문서 답변도 검증이 필요하다.

문서에서 가장 먼저 확인할 것은 목적과 독자다.

예를 들어 같은 장애 내용을 정리하더라도 독자에 따라 문서가 달라진다.

개발팀 내부 공유:
- 상세 로그
- 원인 후보
- 코드 변경 사항
- 재현 방법
- 후속 작업

임원 보고:
- 장애 개요
- 고객 영향
- 조치 현황
- 재발 방지 대책
- 의사결정 필요 사항

고객 공지:
- 발생한 문제
- 이용 불편에 대한 사과
- 현재 조치 상태
- 사용자가 알아야 할 내용

AI가 작성한 문서가 독자에 맞지 않으면 문제가 생긴다.

개발팀 내부 문서에 필요한 상세 기술 내용이 임원 보고서에 너무 많이 들어가면 읽기 어렵다.
반대로 고객 공지문에 내부 시스템명이나 추정 원인이 그대로 들어가면 위험하다.

문서 답변 검토 시 확인할 항목은 다음과 같다.

- 문서 목적에 맞는가?
- 독자 수준에 맞는가?
- 너무 기술적이거나 너무 추상적이지 않은가?
- 확인되지 않은 내용을 단정하지 않았는가?
- 내부 정보가 외부용 문서에 노출되지 않았는가?
- 핵심 결론이 앞에 나오는가?
- 후속 작업이 명확한가?

예를 들어 AI가 고객 공지문에 이렇게 썼다고 해보자.

Redis Cluster 내부 노드 간 통신 지연으로 인해 방송방 입장 API에서 timeout이 발생했습니다.

개발팀 내부 문서라면 괜찮을 수 있다.

하지만 고객 공지문이라면 너무 기술적이고 내부 구조가 노출된다.

외부 공지용으로는 다음처럼 바꾸는 것이 낫다.

일부 시간대에 방송방 입장이 지연되는 현상이 발생했습니다.  
현재 원인 확인 및 조치를 완료했으며, 재발 방지를 위한 추가 점검을 진행하고 있습니다.

AI가 문서를 잘 써도 최종 독자와 공개 범위는 사람이 판단해야 한다.

9. 최신 정보는 반드시 별도로 확인해야 한다

AI는 항상 최신 정보를 알고 있는 것이 아니다.

모델이 학습한 이후에 바뀐 내용은 모를 수 있다.
또 오래된 정보를 최신 정보처럼 말할 수도 있다.

특히 다음 주제는 반드시 최신 확인이 필요하다.

- 클라우드 서비스 가격
- AI 모델 지원 여부
- API 정책
- 라이브러리 최신 버전
- 보안 취약점
- 법률과 규정
- 브라우저 지원 범위
- 제품 출시 일정

예를 들어 AI가 이렇게 답했다고 해보자.

현재 AWS Bedrock에서는 A 모델과 B 모델을 사용할 수 있습니다.

이 답변은 시점에 따라 틀릴 수 있다.

오늘은 맞아도 다음 달에는 모델 목록이 바뀔 수 있다.
리전별 지원 여부도 다를 수 있다.

라이브러리 사용법도 마찬가지다.

AI가 예전 버전 기준 코드를 알려줄 수 있다.

// 예전 버전에서는 맞았지만 최신 버전에서는 deprecated 되었을 수 있음
someLibrary.oldMethod();

최신 정보가 필요한 경우에는 다음 기준으로 확인해야 한다.

- 공식 문서
- 릴리즈 노트
- 가격 페이지
- 보안 공지
- GitHub README
- API Reference

AI 답변은 방향을 잡는 데 사용하고,
최종 확인은 공식 자료를 기준으로 해야 한다.

deprecated는 더 이상 사용을 권장하지 않는 기능을 의미한다.
당장은 동작할 수 있지만, 향후 제거되거나 보안·호환성 문제가 생길 수 있다.

10. 보안 관련 답변은 더 엄격하게 봐야 한다

보안 관련 답변은 특히 조심해야 한다.

AI가 보안 코드를 작성해줄 수는 있지만, 그것이 안전하다는 뜻은 아니다.

예를 들어 AI가 JWT 인증 코드를 만들어줬다고 해보자.

const token = jwt.sign({userId: user.id}, process.env.JWT_SECRET);

이 코드는 동작할 수 있다.

하지만 보안 관점에서는 확인할 것이 많다.

- 만료 시간이 설정되어 있는가?
- 서명 알고리즘은 적절한가?
- JWT_SECRET이 충분히 안전한가?
- 토큰 탈취 시 대응 방법이 있는가?
- refresh token 구조가 필요한가?
- 로그에 토큰이 남지 않는가?
- 권한 정보가 클라이언트에서 조작될 수 없는가?

AI가 “보안상 문제 없습니다”라고 답해도 그대로 믿으면 안 된다.

보안은 공격자의 관점에서 다시 봐야 한다.

AI가 만든 보안 관련 결과는 최소한 다음 기준으로 검토해야 한다.

- 인증: 사용자가 누구인지 확인하는가?
- 인가: 해당 사용자가 이 기능을 사용할 권한이 있는가?
- 입력값 검증: 외부 입력을 신뢰하지 않는가?
- 민감 정보 보호: 비밀번호, 토큰, 개인정보가 노출되지 않는가?
- 로그: 민감 정보가 로그에 남지 않는가?
- 세션 관리: 만료, 재발급, 탈취 대응이 있는가?
- 오류 메시지: 공격자에게 힌트를 주지 않는가?

예를 들어 로그인 실패 메시지를 이렇게 주면 위험할 수 있다.

{
  "message": "존재하지 않는 이메일입니다."
}

공격자는 이 응답을 이용해 어떤 이메일이 가입되어 있는지 확인할 수 있다.

더 안전한 방식은 다음과 같다.

{
  "message": "이메일 또는 비밀번호가 올바르지 않습니다."
}

AI가 만든 코드는 기능 중심으로는 그럴듯할 수 있다.

하지만 보안은 기능이 동작하는 것만으로 충분하지 않다.
악용 가능성까지 함께 검토해야 한다.

11. 비용 관련 답변은 숫자로 다시 계산해야 한다

AI는 비용 추정도 도와줄 수 있다.

하지만 비용 관련 답변은 반드시 직접 계산해야 한다.

AI가 클라우드 비용이나 AI API 비용을 대략 비교해줄 수는 있다.
하지만 실제 비용은 사용량, 리전, 요금제, 할인, 트래픽 패턴에 따라 달라진다.

예를 들어 AI가 이렇게 답했다고 하자.

월 100만 건 정도의 요청이면 비용은 크지 않을 것입니다.

이 답변은 너무 모호하다.

비용을 판단하려면 숫자가 필요하다.

AI API 비용이라면 다음 값이 필요하다.

- 월 요청 수
- 요청당 평균 입력 토큰
- 요청당 평균 출력 토큰
- 사용하는 모델 단가
- 캐시 적용률
- 재시도 비율

예를 들어 다음처럼 계산해야 한다.

월 요청 수: 1,000,000건
요청당 입력 토큰: 1,000
요청당 출력 토큰: 500

월 입력 토큰:
1,000,000 × 1,000 = 1,000,000,000 tokens

월 출력 토큰:
1,000,000 × 500 = 500,000,000 tokens

이후 모델별 단가를 곱해야 실제 비용이 나온다.

클라우드 인프라 비용도 마찬가지다.

- 인스턴스 타입
- 사용 시간
- 데이터 전송량
- 스토리지 사용량
- 요청 수
- NAT Gateway 사용 여부
- CloudFront 사용 여부
- 로그 저장량

AI가 비용을 설명해주는 것은 참고용이다.

최종 판단은 반드시 공식 가격표와 실제 사용량 추정으로 해야 한다.

비용 검토에서는 “비싸다/싸다”보다 “어떤 사용량에서 얼마가 나오는가”가 중요하다.

12. AI 답변을 반대 관점으로 검토한다

AI 답변을 더 좋게 만드는 방법 중 하나는 반대 관점으로 다시 검토하는 것이다.

AI는 처음 답변에서 하나의 결론을 제시할 수 있다.

하지만 그 결론이 항상 최선은 아니다.

예를 들어 AI가 이렇게 답했다고 하자.

이번 기능은 AWS Lambda로 구현하는 것이 적합합니다.

그럴듯한 결론이다.

하지만 바로 받아들이기보다 반대 관점으로 검토해볼 수 있다.

방금 결론에 반대하는 관점에서 검토해줘.

Lambda보다 ECS가 더 나을 수 있는 상황을 정리해줘.

비교 기준:
- 실행 시간
- 배포 방식
- 비용 예측 가능성
- 장애 대응
- 운영 복잡도

그러면 놓친 리스크를 찾을 수 있다.

보고서 작성에서도 유용하다.

방금 작성한 AI 도입 계획을 반대하는 임원 관점에서 검토해줘.

특히 다음 관점으로 리스크를 찾아줘.
- 비용
- 보안
- 운영 부담
- 효과 측정
- 조직 적응

이 방식은 의사결정 품질을 높인다.

AI가 만든 초안이 한쪽으로 치우쳐 있을 때, 반대 검토를 통해 균형을 잡을 수 있다.

특히 다음 상황에서 유용하다.

- 기술 선택
- 클라우드 아키텍처 결정
- AI 도입 전략
- 비용 절감 방안
- 보안 정책
- 조직 운영 개선안

좋은 의사결정은 장점만 보고 하지 않는다.

반대 근거와 실패 가능성까지 검토해야 한다.

AI를 활용하면 이 과정을 빠르게 수행할 수 있다.

13. 여러 답변 후보를 비교한다

AI에게 답변을 하나만 받으면 그 답변이 최선처럼 보일 수 있다.

하지만 실무에서는 여러 후보를 비교하는 것이 좋다.

예를 들어 AI 고객 문의 요약 기능을 만든다고 해보자.

AI에게 하나의 아키텍처만 요청할 수도 있다.

AI 고객 문의 요약 기능 아키텍처를 제안해줘.

하지만 더 좋은 방법은 여러 안을 비교하는 것이다.

AI 고객 문의 요약 기능을 만드는 아키텍처를 3가지로 제안해줘.

각 안은 다음 기준으로 비교해줘.
- 개발 난이도
- 비용
- 보안
- 운영 부담
- 확장성
- 추천 상황

그러면 다음처럼 비교할 수 있다.

이렇게 비교하면 선택지가 명확해진다.

코드 개선도 마찬가지다.

이 코드를 개선하는 방법을 3가지 제안해줘.

1. 최소 수정안
2. 구조 개선안
3. 장기 리팩토링안

각 안의 장단점과 적용 난이도를 비교해줘.

AI에게 하나의 정답만 요구하지 말고,
여러 선택지를 만들게 한 뒤 사람이 판단하는 방식이 좋다.

AI는 선택지를 빠르게 만들어주는 데 강하다.
최종 선택은 현재 일정, 리소스, 위험도, 조직 상황을 아는 사람이 해야 한다.

14. AI 답변을 실무 문서로 다듬는다

AI 답변은 보통 초안 형태다.

실무에서 사용하려면 문서 목적에 맞게 다듬어야 한다.

예를 들어 AI가 다음과 같이 답했다고 하자.

이 기능은 보안상 문제가 있을 수 있으며, 사용자의 개인정보가 외부 API로 전송될 가능성이 있습니다.
따라서 마스킹 처리를 해야 하고, API 호출 전 로그를 확인해야 합니다.

내용은 맞지만 보고서에 넣기에는 조금 거칠다.

임원 보고용으로는 다음처럼 다듬을 수 있다.

AI 기능 적용 시 사용자 개인정보가 외부 API로 전송될 가능성이 있으므로,
API 호출 전 개인정보 마스킹 및 로그 저장 기준을 먼저 정립할 필요가 있습니다.

개발팀 작업 항목으로는 이렇게 바꿀 수 있다.

작업 항목:
- AI API 호출 전 개인정보 마스킹 처리 추가
- 요청/응답 로그 내 민감 정보 저장 여부 점검
- 외부 API 전송 가능 데이터 기준 정의

고객 공지용이라면 더 다르게 써야 한다.

고객님의 개인정보가 안전하게 처리될 수 있도록,
AI 기능 적용 전 데이터 보호 기준을 검토하고 있습니다.

같은 내용이라도 문서 목적에 따라 표현은 달라진다.

AI 답변을 실무 문서로 다듬을 때는 다음을 확인하자.

- 독자에게 맞는 표현인가?
- 결론이 먼저 나오는가?
- 불필요한 기술 설명은 줄였는가?
- 해야 할 일이 명확한가?
- 책임 소재를 과도하게 단정하지 않았는가?
- 외부 공개 문서에 내부 정보가 포함되지 않았는가?

AI가 만든 문장은 재료다.

그 재료를 보고서, 공지문, 작업 지시서, 개발 문서로 가공하는 것은 사용자의 몫이다.

15. AI 답변 개선을 위한 피드백 방법

AI 답변이 마음에 들지 않을 때는 “다시 해줘”라고만 말하지 않는 것이 좋다.

피드백도 구체적이어야 한다.

나쁜 피드백은 다음과 같다.

별로야.
다시 해줘.
더 좋게 해줘.

이런 피드백은 무엇이 문제인지 알려주지 않는다.

AI는 다시 답변을 만들지만, 같은 문제가 반복될 수 있다.

좋은 피드백은 문제와 방향을 함께 알려준다.

내용은 맞는데 너무 일반적이야.
우리 서비스가 라이브 방송 플랫폼이라는 점을 반영해서 다시 작성해줘.

문장이 너무 길어.
임원 보고용으로 한 문장당 2줄을 넘지 않게 줄여줘.

기술 설명은 좋은데 결론이 늦게 나와.
결론을 먼저 쓰고, 근거를 뒤에 배치해줘.

리스크 설명은 있는데 대응 방안이 부족해.
각 리스크별로 현실적인 대응 방안을 추가해줘.

AI 답변을 개선할 때 자주 쓰는 피드백 유형은 다음과 같다.

- 너무 길다 → 줄여달라고 한다.
- 너무 짧다 → 예시를 추가해달라고 한다.
- 너무 일반적이다 → 현재 상황을 반영하게 한다.
- 너무 기술적이다 → 독자 수준에 맞춘다.
- 결론이 약하다 → 결론을 먼저 쓰게 한다.
- 근거가 부족하다 → 판단 근거를 추가하게 한다.
- 실행안이 없다 → 다음 액션을 정리하게 한다.

AI와의 작업은 한 번에 끝내는 것이 아니라,
초안을 받고 피드백을 주면서 점점 원하는 결과에 가까워지는 과정이다.

16. 실무 적용 전 최종 체크리스트

AI 답변을 실제 업무에 사용하기 전에는 마지막으로 체크리스트를 통과해야 한다.

코드, 문서, 설계, 비용, 보안 등 유형별로 확인할 항목이 다르다.

16.1 공통 체크리스트

- 사실과 추정이 구분되어 있는가?
- 근거 없는 단정이 없는가?
- 우리 상황과 맞는가?
- 중요한 조건이 빠지지 않았는가?
- 최신 정보가 필요한 내용은 확인했는가?
- 민감 정보가 포함되어 있지 않은가?
- 결과물을 사용할 대상에 맞는 표현인가?

16.2 코드 체크리스트

- 실제로 실행되는가?
- 테스트를 통과하는가?
- 현재 프로젝트 버전과 맞는가?
- 예외 처리가 되어 있는가?
- 보안상 위험한 부분은 없는가?
- 기존 비즈니스 로직을 깨지 않는가?
- 로그에 민감 정보가 남지 않는가?
- 팀 코드 스타일과 맞는가?

16.3 SQL 체크리스트

- 실제 DB에서 실행되는가?
- 실행 계획이 적절한가?
- 필요한 인덱스가 있는가?
- 대량 데이터에서도 안전한가?
- 잠금이나 부하 문제가 없는가?
- SELECT, UPDATE, DELETE 범위가 의도와 맞는가?
- 운영 DB에서 바로 실행해도 안전한가?

특히 UPDATE, DELETE 쿼리는 더 조심해야 한다.

DELETE
FROM users;

조건이 빠진 쿼리는 치명적일 수 있다.

운영 환경에서는 반드시 트랜잭션, 백업, 조건 확인, 영향 건수 확인이 필요하다.

16.4 문서 체크리스트

- 독자에게 맞는 문체인가?
- 결론이 앞에 있는가?
- 불필요하게 장황하지 않은가?
- 확인되지 않은 내용을 단정하지 않았는가?
- 내부 정보가 외부 문서에 노출되지 않았는가?
- 후속 작업이 명확한가?
- 책임 표현이 과하거나 부족하지 않은가?

16.5 보안 체크리스트

- 개인정보가 노출되지 않는가?
- 인증과 권한이 분리되어 있는가?
- 입력값 검증이 있는가?
- 토큰, 비밀번호, API Key가 노출되지 않는가?
- 로그에 민감 정보가 남지 않는가?
- 오류 메시지가 공격자에게 힌트를 주지 않는가?
- 외부 API 전송 데이터가 적절히 통제되는가?

17. AI 답변을 잘 활용하는 개발자의 태도

AI 답변을 잘 활용하려면 태도가 중요하다.

AI를 무조건 믿어서도 안 되고,
AI를 무조건 불신해서도 안 된다.

AI는 빠르게 초안을 만들고,
여러 선택지를 제안하고,
놓친 관점을 찾아주는 데 매우 유용하다.

하지만 최종 판단은 사람이 해야 한다.

개발자는 AI를 다음과 같이 활용하는 것이 좋다.

- 초안 생성 도구
- 아이디어 확장 도구
- 코드 설명 도구
- 체크리스트 생성 도구
- 반대 관점 검토 도구
- 반복 작업 보조 도구

반대로 다음과 같이 사용하면 위험하다.

- 검증 없이 운영 코드에 반영
- 보안 판단을 AI에게 전적으로 위임
- 비용 계산을 AI 답변만 믿고 결정
- 최신 정책을 확인하지 않고 적용
- 내부 정보를 마스킹 없이 입력
- AI 답변을 공식 입장처럼 사용

AI는 개발자의 판단을 대체하는 도구가 아니다.

개발자의 판단을 더 빠르고 넓게 도와주는 도구다.

18. 정리

AI 답변은 완성품이 아니라 초안이다.

AI는 빠르게 답을 만들 수 있지만, 그 답이 항상 정확하거나 충분하거나 최신이라는 보장은 없다.

그래서 AI 답변을 받은 뒤에는 반드시 검토해야 한다.

먼저 사실, 추정, 의견, 제안을 구분해야 한다.
근거 없는 단정은 다시 확인해야 한다.
누락된 내용이 없는지도 살펴봐야 한다.

코드는 실행하고 테스트해야 한다.
SQL은 실행 계획과 데이터 규모를 봐야 한다.
문서는 독자와 목적에 맞게 다듬어야 한다.
최신 정보는 공식 문서로 확인해야 한다.
보안과 비용은 더 엄격하게 검토해야 한다.

AI를 잘 쓰는 개발자는 AI에게 한 번 물어보고 끝내지 않는다.

AI가 만든 초안을 검토하고, 반대 관점으로 다시 보고, 여러 후보를 비교하고, 실무에 맞게 다듬는다.

이 장에서 기억해야 할 핵심은 하나다.

AI 답변은 빠른 출발점이다.
하지만 실무에 적용할 수 있는 결과로 만드는 것은 개발자의 검증과 판단이다.

6장 핵심 요약